1. Field of the Invention
The invention relates generally to dynamic adaptation of code, and, more specifically, to dynamic adaptation by a delegation chain of a code to be executed as an isolated computation.
2. Description of the Related Art
The ability to dynamically inject code into a code unit is addressed for a variety of reasons. For example, in some implementations every newly created computation subject to resource usage policies registers itself with computations dispensing resources and imposing these policies. The decision with which resource dispensing computation to register is taken at runtime. The registration sequence is independent from the application code intended to run in the computation. Typically, such registration sequences are injected before the original code unit entry point and may require deregistration sequences that should be run when the computation is being shutdown.
Current implementation techniques either hardcode the registration sequence and thus create a dependency between implementations of otherwise unrelated APIs, or require the application code to use special wrapper methods to create and start code units in order to ensure that they will be subject to the specified resource management policies.
Similarly, imposing security, management (e.g., JMX-style), logging policies, etc., on isolated computations requires injecting sequences of code into code units submitted for execution. Aspect Oriented Programming (AOP) environments, such as AspectJ, impose aspects statically, and do not support runtime selection and manipulation of aspects.
Dynamic AOP environments (JBossAOP, AspectWerkz, Prose, Nanning Aspects) concentrate on dynamically adding aspects to already executing applications, which raises concerns regarding preservation of application integrity (e.g., invocations of an advised method may be already executing when an aspect is applied, a persistence aspect may be introduced in the middle of a transaction, etc). The existing Dynamic AOP environments provide the means of weaving (and a unweaving) a single aspect at a time and are not concerned with how aspects are composed, and do not attempt to reflect the fact that different parts of an application have varying degrees of competence or privilege to apply aspects. Although these environments provide operations that can be repeated to unweave multiple aspects, these environments do not track such operations in a manner that can be programmatically explored. Furthermore, the ‘dynamic’ character of these environments is limited. The dynamic AOP environments lack a structural mechanism for making runtime decisions for unweaving aspects. No mechanism is provided to undo aspect weaving, when it is discovered that already applied aspects are not composable.